Scoped to the #2459 part of this PR, against head 9331d35. Filed that issue; reviewed this against the failure observed there.

The core wiring is sound: take_self_publishes runs before mark_complete wipes the in-flight entry, kind 9 is in the Mentions-rule REQ so the echo does reach the counting site in the default config, and every PromptOutcome::Ok construction in pool.rs now carries the batch without any path re-entering requeue (checked all of them). Full buzz-acp suite passes locally on this branch. Two paths produce false "couldn't publish" notices:

1. Counting is gated on ignore_self. note_self_publish only runs inside if config.ignore_self && … (lib.rs). Under --no-ignore-self the counter never increments, so every successful mention turn posts the failure notice into the channel. The observation belongs above the gate: count self-authored kind-9s unconditionally, then let ignore_self decide the drop.

2. The counter is consumed at turn end, but the echo arrives on an independent path. The reply's echo comes in over the ws subscription; turn completion comes over the pool result channel — nothing orders them. The CLI publishes via REST, so a ws drop at turn end doesn't stop the reply from landing in the channel, but the reconnect since-replay delivers the echo after handle_prompt_result has already consumed a zero counter and posted the notice. Net effect: real reply in the channel with a spurious "I couldn't publish" right behind it — clustering exactly when the relay is unstable, which is when users are most inclined to believe the notice. A grace window closes it: don't decide at turn completion; schedule the check a few seconds later and re-read a counter that survives mark_complete until the deferred check consumes it.

Smaller notes:

• SubscribeMode::All batches carry prompt_tag: "all", so mentions get no protection in that mode. If deliberate (every event fires a turn there, so zero-publish isn't anomalous), worth a comment in batch_expects_channel_reply.
• A mention answered with only a reaction (kind 7) or a pure side effect (no channel message) posts the notice. Probably acceptable; noting it since it's user-visible.

Regression coverage that would catch 1 and 2: an ingest-level test driving a mention turn to Ok with (a) echo delivered before completion → no notice, (b) echo delivered after completion → no notice (fails today), (c) --no-ignore-self + echo delivered → no notice (fails today). The silent_reply.rs unit tests exercise the pure function only, which is why neither path surfaced.